Restore literal false in parameter expansion#68
Restore literal false in parameter expansion#68jgraichen merged 4 commits intojgraichen:mainfrom MrSerth:boolean_query_parameters
Conversation
The previous implementation is handling expected query parameters with a `false` value in an unintended manner. Rather than appending the parameter as expected, it is omitted. This is in contrast to parameters not included in the pattern, where a `false` value would be appended. In a test-driven development fashion, this commit adds a failing test first and thereby allows working on the bug more easily.
|
Thanks for reporting. I took a brief look, and it seems to get more complicated, since context 'with false' do
let(:params) { {id: false} }
it { expect(expanded.to_s).to eq 'http://test.host/resource/' }
endI tend to change this to include |
|
Thanks for checking! I saw this "conflicting" test too, but wouldn't consider it a conflict necessarily: The test you cited is regarding the path parameters, not regarding query parameters. Theoretically, one (path) could behave differently than the other (query). Of course, I understand that this might be even more misleading... Also, I was unsure about the inclusion of |
|
Unfortunately, Restify does not parse and fill URI templates, but explicitly delegates to
|
|
Alright. Then, I'll refactor the |
The previous implementation is handling expected query parameters with a `false` value in an unintended manner. Rather than appending the parameter as expected, it is omitted. This is in contrast to parameters not included in the pattern, where a `false` value would be appended. In a test-driven development fashion, this commit adds a failing test first and thereby allows working on the bug more easily.
|
Thanks! I do like |
|
No problem -- I liked |
|
let(:pattern) { '/resource/{id}{?q*}' }
context 'with additional nil parameters' do
let(:params) { {id: '5', abc: nil} }
it { expect(expanded.to_s).to eq 'http://test.host/resource/5?abc' }
end |
Restore putting literal false values into query params. Previously,
literal false values were ignored from template expansion, resulting in
unexpected queries:
get(params: {public: true, hidden: false}) -> /?public=true
This commit changes the parameter expansion to include `false` as
a literal value. This does include `false` in path params, which will
result in e.g. `/resource/false` now, but that seems "more correct" too.
|
Right, this part is also covered in the specs already: restify/spec/restify/relation_spec.rb Lines 75 to 79 in fe526fe I would still suggest adding the explicit test for the placeholder (especially since it is removed completely), just to have this behavior documented in the code: https://github.com/MrSerth/restify/blob/8318c08d343336e87f28a50a25d0092688320536/spec/restify/relation_spec.rb#L62-L67 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #68 +/- ##
==========================================
+ Coverage 95.88% 96.04% +0.15%
==========================================
Files 21 21
Lines 681 683 +2
==========================================
+ Hits 653 656 +3
+ Misses 28 27 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
If a params hash contains template placeholders with string and symbol keys, both are removed but symbol keys preferred. Technically, the preferred key is an implementation detail in Addressable::Template, but for now the tests here depend on that.
MrSerth
left a comment
There was a problem hiding this comment.
Thanks for taking care of fixing the errounous behavior and specifying the behavior of overlapping keys. I really appreciate your efforts for this! 👍
Restore putting literal false values into query params. Previously,
literal false values were ignored from template expansion, resulting in
unexpected queries:
This commit changes the parameter expansion to include
falseasa literal value. This does include
falsein path params, which willresult in e.g.
/resource/falsenow, but that seems "more correct" too.The previous implementation is handling expected query parameters with a
falsevalue in an unintended manner. Rather than appending the parameter as expected, it is omitted. This is in contrast to parameters not included in the pattern, where afalsevalue would be appended.In a test-driven development fashion, this commit adds a failing test first and thereby allows working on the bug more easily.
The bug investigated (and covered through the test) has led to real-world failures. Let me take an example from openHPI. Consider a course that is hidden:
In a public export for MOOChub, this course should not be shown:
The request made to the respective service, however, does not include the

hiddenquery parameter:Consequently, the course is shown on <moochub.org>:
